fix(tracing): register exporters added after initialization - #810
Draft
feng-95 wants to merge 1 commit into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dependency
ffbf295.387a856and was not modified.feat/exporterwas rebased onto mergedorigin/main; the only PR increment is018cc56dbad7e8fcf192276c7874cd3c252f194d.main.Summary
BaseExporter.register(provider)to attach an exporter processor and resource attributes exactly once per provider.OpentelemetryTracer.add_exporter()so exporters enabled after tracer initialization are registered immediately.APMPlusExporterand its meter uploader but skip only its trace processor registration. The external provider remains responsible for trace delivery.ENABLE_APMPLUS=trueis also set.Root cause
Appending an exporter to
tracer.exportersafter the globalTracerProviderhad already been initialized did not attach the exporter span processor. The exporter object existed, but it could not receive or upload spans. The earlier global-provider fix also removed the APMPlus exporter object entirely, which prevented its metrics path from being retained.Validation
pytest -q tests/test_tracing.py tests/test_tracing_content.py— 26 passed after the rebase.ENABLE_APMPLUS× preconfigured provider × manual exporter unit-test matrix passed.git diff --checkpassed.go 1.23.0/toolchaindirectives; GitHub CI remains the authoritative full-hook check.End-to-end matrix
gen_ai_chat_countENABLE_APMPLUS=true, no global provider925974450246f25a786453722f2fa1c6)APMPlusExporter, no global provider876a1f163e75e5c879553c5729b90e19)localhost:4318only24d0a0f3d2fecd504bd7645cecb7c1ff)localhost:4318onlyd6a3bcd406bd871962d54fac9682a3c9)localhost:4318onlydfdd3f92dcf50ac26b5efbe6b741a27f)opentelemetry-instrument+ env enabledlocalhost:4318only50bc24477fb2f86f10a8c120178b3dff)The local OTLP relays observed zero duplicate
(trace_id, span_id)pairs in every scenario. For each metrics-enabled scenario, the APMPlus time series hadcurrent=min=max=1, including after explicitforce_flush()and process shutdown.Known boundary
opentelemetry-instrumentinstalls a zero-reader globalMeterProvidereven withOTEL_METRICS_EXPORTER=none. The #810 meter uploader cannot replace it, so the last scenario has no metrics. This is accepted for #810 and is fixed separately by #814.Test report
/Users/bytedance/go/src/code.byted.org/byteapm/docs-feng/veadk-python/VeADK_Exporter_Register_增量测试报告.md